1. Field of the Invention
The present invention relates to a technique for processing computer form data and, more particularly, to a system and method of processing computer form data by dynamically converting data field names of a computer form such as an HTML form, into recognizable data field names using mapping information.
2. Description of the Related Art
As the largest network of computers in the world, the Internet is revolutionizing the business environment. Through the Internet, merchants can offer their products and services to anyone who accesses their Web pages. As a result, online shopping has become extremely popular and merchants are eagerly seeking ways to improve the online shopping experience of the users.
FIG. 1 illustrates a typical e-commerce arrangement in which a potential purchaser, referred to generically herein as a “user”, and a merchant transact business. As shown in FIG. 1, a user's computer 10 is connectable to the Internet 30 through a known device such as a modem. A merchant's server 20 is also connectable to the Internet 30, thereby establishing a communication connection between the user and the merchant.
A Web browser 12 is stored on the user's computer 10. A Web browser is a client program which displays and allows interaction with Web pages that are typically written in the well known HyperText Markup Language (Ht). The merchant's server 20 includes a HyperText Transport Protocol (HTTP) server 22 for managing communications to and from the user's browser 12, and a form processing program (FPP) 24 for processing form data received by the HTTP server 22 from the browser 12.
FPP's are well known and typically comprise computer software that processes form data input to the FPP. In older systems, many of which are still in operation today, the FPP 24 is programmed to recognize only merchant-specific (also called “proprietary”) form data.
In online shopping, a merchant typically posts its product and/or service information on Web pages stored on its server 20. In a well known manner, these Web pages can be downloaded by a user and displayed on the user's computer 10 under control of the Web browser 12. A typical Web page can include embedded images, video or audio segments, and references to one or more other Web pages, all of which may be used to display product information to the user in an attempt to elicit a sale.
When the user is ready to make an online purchase, the user transmits an order form request to the HTTP server 22 of the merchant's server 20, which in turn transmits an HTML file containing information for displaying an order form to the user's browser 12. The browser 12 then displays the order form on the screen of the users's PC 10 according to the contents of the HTML file.
Typically, an order form includes data fields for soliciting relevant data pertaining to the user and/or the potential purchase, such as the user's personal information (e.g., name, address, phone number, etc.), financial information (e.g., credit card number, expiration date, etc.), product information, shipping information, and any other information needed to complete the online purchase. A very simple example of such a form as it would appear on a user's computer screen is shown in FIG. 2. The order form of FIG. 2 includes a “Title” field 202, a “Last name” field 204, a “First name” field 206, a “Middle name” field 208, and a “Part number to order” field 210. The user fills in the requested information and transmits the form back to the merchant's server 20 where it is processed by the FPP 24.
FIG. 3 illustrates an example of an HTML form file (referred to herein as an “HTML form”) which generates the order form of FIG. 2. As can be seen in FIG. 3, the HTML form file, like all HTML files, comprises a series of coded commands which, in a well known manner, specifies the layout, text, and operations of the displayed Web page. Some of the coded commands in the HTML form illustrated in FIG. 3 are executory in nature, i.e., they are instructions which will direct a processor to take certain actions. For example, part P1 of the HTML file identifies a location (“cgi-bin/ncommerce3/NewOrder”) on the merchant's server 20 to which the user's data will be submitted. Other coded commands are directed to the actual display on the user's computer screen. For example, part P2 displays different name titles (e.g., “Mr.” or “Ms.”) from which the user can select.
Part P3 displays an input area for the user's last name (i.e., the “Last name” field 204 of FIG. 2), where the field name is “proprietary_lname”. Likewise, part P4 displays an input area for the user's first name (field name=“proprietary fname”); part P5 displays an input area for the user's middle name (field name=“proprietary_mname”); and part P6 displays an input area for the part number to be ordered by the user (field name=“proprietary_pnumber”). Part 7 displays a “Submit Order” button on the form page so that the user can submit the input data by clicking on this button.
Once the user inputs all the required data into the data fields of the HTML form and clicks the “Submit Order” button, the browser 12 prepares, in a well known manner, an HTTP Post based on the user's input data. The HTTP Post is essentially a “stripped” version of the now-completed HTML form, i.e., the HTTP Post contains the field name(s) and the user input associated with the field name(s), but without the information which specifies the graphical layout of the displayed HTML form. The browser 12 transmits the prepared HTTP Post to the merchant's HTTP server 22 over the Internet 30 for processing.
When the merchant's HTTP server 22 receives the HTTP Post from the user's browser 12, the HTTP server 22 routes the HTTP Post to the FPP 24. Since the FPP 24 has been previously configured to recognize and process the merchant's proprietary names as the field names for the HTTP Post data, the FPP 24 is able to correctly process the HTTP Post data and utilize the input user data.
Since the system illustrated in FIGS. 1-3 uses unique proprietary field names, the system of one merchant cannot process data associated with the proprietary field names of another merchant. This creates a major problem in the e-commerce industry because exchange of data between two or more merchants cannot be performed without having to extensively modify their existing systems. This problem also causes an extreme inconvenience to Internet users because the users have to input the same information (e.g., name, address, etc.) each time they conduct business with a new merchant. This deters many Internet users from shopping online or conducting other online transactions.
Recently, a group of companies, including IBM, American Express, Compaq, Visa, MasterCard, and others, have collaborated to standardize the use of field names on merchant Web sites. The format is called Electronic Commerce Modeling Language (ECML) and employs a set of uniform field names which are included in the HTML code on online order forms. FIG. 4 illustrates a listing of several ECML field names and corresponding general descriptors identifying the data field to which they pertain. In ECML application, a consumer has to input the data just once and this data is stored in a “digital wallet,” typically on the user's PC. The digital wallet is accessed to provide the stored data to each merchant Web page whenever such data is requested. The user's server automatically “fills out” the order form and transmits it to the merchant's server as discussed above. Such a mechanism is convenient to the user since the user has to input the user's data just once, thereby enhancing the user's online shopping experience.
A problem arises, however, when a merchant using an existing or “non-standardized” system wants to transact business with a user utilizing a digital wallet or similar standardized format. Using the proprietary field names to refer to the data fields (e.g., using “proprietary_lname” to refer to the “last name” field) may serve the needs of the merchant when the user directly inputs the requested data to the merchant's form. But when the user data is input via, for example, a digital wallet containing standardized ECML fields, the digital wallet refers to the data fields using the ECML field names (e.g., using “Ecom_ShipTo_Postal_Name_Last” as the “ship to last name” field) and the merchant's system will not recognize the ECML field names. As a result, errors will occur and the merchant may lose potential sales and customers.
One way to address this problem would be for the merchant to examine its system in detail and to replace the proprietary field names, wherever they are used in the system, with the standardized (e.g., ECML) field names. This process can be time-consuming, highly expensive, and complicated, and is prone to error and malfunctions since each use of the proprietary field names must be re-keyed with the standardized field names throughout the entire system. On the other hand, if the merchant fails to replace it's proprietary field names with the standardized field names, the merchant's system will not be able to process the user's data associated with the standardized field names since the merchant's system will not recognize the standardized field names. The merchant may lose potential customers and sales and may ultimately lose his or her competitive edge to compete in the field of e-commerce.
Accordingly, an extremely urgent need exists for a simplified technique to be developed wherein a merchant can process user's data associated with the non-proprietary field names (e.g., ECML field names or any standardized field names) without having to change the proprietary field names throughout their system. Such a technique will enhance the online experience of Internet users and will further facilitate the exchange of information do and data among e-commerce businesses.